>Angelo 'kENpEX' Pesce <ken### [at] uniplanit> wrote:
>: 1) Programmable shaders
>
>  A nice feature which we all look forward to having some day.
I hope so too... I know it's a bit hard to do so I don't think it will
be done soon, well at least if povray team don't want to integrate
povman patch into the official povray (that is a really really good
idea imho)
>
>: So I've understood that having something like compiled-plugins is not
>: possible with povray... Now what? the only alternative I can think of
>: is making them with scripts, mabye supporting directly the renderman
>: specification (povman is great)... The problem with this is that's
>: really really harder to do, and to do it fast!
>
>  If PRMan and other renderers can do it fast, why not povray?
well prman is not a raytracer, that's why it's so fast... I don't have
benchmarked povman and I know that bmrt is slooow so I don't know if
"other renderers" can really do it so fast :P Btw, surely it's
doable... (plus we have to remember that povray will always be a
little slower because we can't include anything that is not
portable... like a jit-compiler system for this shading-scripts for
example)

>: Mabye a compiled script
>: (like renderman system) should be used, something like java-vm...
>
>  Well, of course.
>  (Currently functions are byte-compiled and executed by a VM, so it would
>really be just an extention to the current VM implementation.)
Really? I didn't know that... As I sayied in another post, I would
really like to have a tech doc about povray... :/

>: 2) Focus more on rendering speed than on adding new rendering
>: algorithms for the future
>  Of course speed is a really important issue. The problem is that it's not
>as easy as it may sound. POV-Ray already uses very advanced optimization
>techniques for speed (vista buffers, lights buffersm bounding box hierarchies,
>octrees for meshes...). Getting even more speed can be really complicated,
>and require quite a lot of research on high-end algorithms.
As my main hobby is optimizing stuff, I know that it's really hard :P

>: 3) Support for nurbs surfaces and subdivision surfaces, with
>: automatic, adaptive tessellation (rulez!)
>  Perfectly possible. Not at all improbable some day.
This is really important imho, if we want to see povray as a raytracer
for commercial modellers

>: 4) Blurred reflection
>  You can already do blurred reflection (see my other post where I show
>an example). You can also make blurred refraction currently as well.
I know, but as U can read in another reply, you can do it via a trick,
and I don't know why I should do that via a trick...

>  Besides, I think that the idea of not including the megapov blurred
>reflection is that the team wants to implement something more general and
>versatile, which can used not only for blurred reflection, but for many,
>many other related things as well.
I hope so...

>: Adaptive DOF, the same stuff as above...
>  Povray's focal blur *is* adaptive. What do you think those 'confidence'
>and 'variance' values are for?
As I told in another post, I were not sure that povray did not already
have this feature

>: 5) compiled scene-scripts support.
>  This is practically identical to request 1.
>: 6) a rendering strip distribuiton server/client tool (external) over a
>: tcp/ip network...
>  This has been taken into account long time ago. Be assured that every
>possibility will be carefully studied. (It's not like the developers wouldn't
>*want* to add support for that).

Actually someone proposed to make a .NET tool... I think that a java
tool will be really good, as java has networking features and it's
portable and secure for that

>: 7) displacement mapping
>  Not possible.
>  (Well, possible for meshes, but then you need to tesselate the objects.)

So at last I think I made a reasonable wish list here... Who knows,
mabye someone of the pov-team will listen to my wishes somedays...
Keep up the good work...

Post a reply to this message